1/4 october 1999 AN1158 application note uniform vs. boot block flash architectures contents n introduction n blocks n uniform block architecture n boot block architecture n data categorization n conclusion introduction the choosing between a uniform block and a boot block can trouble designers far more than the choice merits. many appli- cations using flash do not make use of flashs internal block architecture and therefore ignore it. this application note aims to categorize the data types stored in flash memory and help the designer choose which type of block architecture they require. blocks the difference between eeprom and flash, from a system view-point, is the way that the two types are erased. eeprom can be erased one byte at a time, whereas flash can only be erased one block at a time. typically a block contains 64 kbytes, though other block sizes exist. because flash can only be erased in blocks, changing a single memory location in the block is not straight forward. there are many different algorithms for storing data in flash that allow single parameters to be updated without reading the entire block, erasing it and re-programming it. read and program operations are independent of blocks. bytes (or words) can be read individually, regardless of block boundaries. erased bytes (or words) can be programmed indi- vidually too. uniform block architecture all the blocks in a uniform block flash memory are the same size. table 1 lists some typical parts, together with the number of blocks in them and their block sizes. table 1. typical uniform block flash uniform block architecture flash memories are usually used in applications that use all blocks for the same purpose, for exam- ple for a flash file system. flash size number of blocks block size m29f010b, m29w010b 128kb x8 8 16 kbytes m29f040b, m29w040b 512kb x8 8 64 kbytes m29f080a 1024kb x8 16 64 kbytes m29f016b 2048kb x8 32 64 kbytes
AN1158 - application note 2/4 boot block architectures boot block flash memory usually contains four different sizes of block. usually there are one boot block, two parameter blocks and a small main block as well as the normal main blocks. the boot block, param- eter blocks and small main block can be located at the top or bottom of the flashs memory space, de- pending on whether a top boot block or bottom boot block part is chosen. table 2 gives the block address locations in the m29w004bb boot block memory. table 2. m29w004bb block addresses the boot block of the m29w004bb is positioned at the bottom of the flashs address space because many microprocessors have their reset vector at 0000h. if the flash is mapped to address 0000h of the microprocessors address space then the microprocessor can boot from the flashs boot block. there are many microprocessors that boot from the bottom of their memory space, such as the st10, motorola 68000 series, power pc etc. the top boot block equivalent, the m29w004bt, has the boot block at the top of the flashs address space. figure 3 shows the block address locations for the m29w004bt. table 3. m29w004bt block addresses top boot block flash memory are intended for microprocessors that begin execution by reading from the top of their memory space. typical examples include intel i960, 80x86 etc. size (kbytes) address range block type 64 70000h-7ffffh main block 64 60000h-6ffffh main block 64 50000h-5ffffh main block 64 40000h-4ffffh main block 64 30000h-3ffffh main block 64 20000h-2ffffh main block 64 10000h-1ffffh main block 32 08000h-0ffffh small main block 8 06000h-07fffh parameter block 8 04000h-05fffh parameter block 16 00000h-03fffh boot block size (kbytes) address range block type 16 7c000h-7ffffh boot block 8 7a000h-7bfffh parameter block 8 78000h-79fffh parameter block 32 70000h-77fffh small main block 64 60000h-6ffffh main block 64 50000h-5ffffh main block 64 40000h-4ffffh main block 64 30000h-3ffffh main block 64 20000h-2ffffh main block 64 10000h-1ffffh main block 64 00000h-0ffffh main block
3/4 AN1158 - application note data categorization some applications have no need to make use of the block architecture. designs using flash purely for code storage (as eprom or rom is used) need only erase the whole memory and reprogram it. the flash offers advantages over eprom in that the hardware can be built and tested with a test program prior to the application program being loaded. using flash alleviates the need to remove any components since the application can be programmed onto the board without removing the flash. two or more prod- ucts may share the same hardware, but include different features that are dependent on the application software. many applications do, however, make good use of the erase and reprogram facilities of flash. the infor- mation that is stored in the flash can be categorized in to boot code, application code, user parameters and user data. boot code is the code and data that the microprocessor requires to boot. if this is to be included in the flash then ideally a boot block flash would be used. boot code rarely exceeds the 16 kbyte size of the typical boot block. the boot block should never be erased and many products will protect their boot block to ensure this. the boot code could include functionality to replace the application code. if the application code becomes corrupt then the boot code can replace it. if the boot code becomes corrupt the system may become unusable and the flash may need to be removed from the board for reprogramming. application code is the code that the user sees running. often the application code will not be run from the flash, but will be copied into another memory, such as dram, before being run. many systems have 32-bit wide dram, but only 8-bit wide flash, so running from dram is faster. the boot code is often re- sponsible for copying the application code before running it. the application code does not need different blocks, it is usually replaced all at once, so one erase operation is sufficient. user parameters configure the system as the user likes it. many systems do not have very many options, and a 64 kbyte block is overkill for most user settings. the parameter blocks provide an ideal storage solution for user settings. since there are two parameter blocks one can be erased while the other stores the current parameters. parameter blocks erase quickly, since they are small, so the user does not have to wait long for the parameter blocks to erase. user data can be any data the user wishes to store. it may include flash file systems, databases, etc. uniform blocks are best for user data storage because then any erased block can be used to store the data from another block when it is changed. as an example consider how a pc bios might use a flash memory. a top boot block memory would be chosen to boot the 80x86 microprocessor. the bios would take the place of the application code, being shadowed into dram before execution. the bios settings would be stored in the parameter blocks so that, in the event of the battery backed-up sram failing, the bios settings would still be valid. finally the remaining flash (all main blocks, so uniform in size) would be used for a flash file system that contains the operating system and other applications. by contrast a pcmcia flash card would use uniform block flash in order to simplify the implementation of a flash file system. conclusion choosing between uniform block and boot block flash memory requires knowledge of what data will be stored in the flash memory. many applications do not make use of the block architecture, and therefore they can use uniform or boot block parts. other applications use different areas of the flash for different purposes, boot block architectures are advantageous to them. finally some applications treat all blocks the same and are therefore more suited to uniform block architectures.
AN1158 - application note 4/4 if you have any questions or suggestion concerning the matters raised in this document please send them to the following electronic mail address: ask.memory@st.com (for general enquiries) please remember to include your name, company, location, telephone number and fax number. information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the co nsequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specifications mentioned in this publicati on are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics prod ucts are not authorized for use as critical components in life support devices or systems without express written approval of stmicroelectro nics. the st logo is registered trademark of stmicroelectronics a 1999 stmicroelectronics - all rights reserved all other names are the property of their respective owners. stmicroelectronics group of companies australia - brazil - china - finland - france - germany - hong kong - india - italy - japan - malaysia - malta - morocco - singapore - spain - sweden - switzerland - united kingdom - u.s.a. http://www.st.com
|
